Bug Proofing Visual Basic: A Guide to Error Handling and Prevention
(Publisher: John Wiley & Sons, Inc.)
Author(s): Rod Stephens
ISBN: 0471323519
Publication Date: 11/01/98

Part One
Work Environment

This may seem like a strange place to begin. It may seem at first glance as if work environment has nothing to do with programming or programming ability. I have known programmers who worked best between 10:00 P.M. and midnight, and others who worked best between 7:00 A.M. and 9:00 A.M. I have known some who wore faded jeans and T-shirts, and others who wore suits and ties every day.

While time of day and attire may have little to do with a specific programmer’s effectiveness, other environmental factors and work habits can have a huge impact. A distracting or tense environment can give developers a self-fulfilling attitude of defeat. Poor work habits can ruin a programmer’s productivity.

For example, consider a programmer who codes when tired, rushes through tasks to meet scheduled deadlines, and releases code without testing it first. Now consider another programmer who codes only when alert, carefully designs routines before implementing them, and would rather release code a day late than release it without testing. Which programmer is more likely to introduce bugs?

The chapters in this part of the book explain attitudes and work habits you should develop to ensure that you produce code that is as bug free as possible the first time. If the code you write is correct, you will not need to fix it later. It may take a little longer to do things right the first time, but the time you will save in debugging will repay you many times over.

A Reminder

Remember, the guidelines presented in this book are not intended to be unalterable rules carved in stone. They are just suggestions that will hopefully guide you past some of the pitfalls that have wasted my time over the years. They were just easier to phrase as rules instead of filling them with expressions like “you might benefit from...” and “I have sometimes found...” If something does not fit your project’s style, by all means, change it.

CHAPTER 1
Programming Philosophy

Programming is a mental task, yet many programmers work with no mental discipline. In bug prevention, detection, and removal, mental attitude is crucial. If you assume that bugs are unavoidable, you will create bugs. If you assume the bugs can be fixed during final testing, you may find so many bugs at the end of the project that you can never finish. If you release your code before you test it, you are guaranteed someone else will find your bugs before you do.

This chapter explains how certain ways of thinking naturally lead to bugs while others prevent them. Some of these concepts may seem strange at first. After a while, they will become as straightforward as asking yourself, “Do I want a bug here, or not?”

Manage Properly

Managers rarely write the majority of the code on a project, so it might seem odd to have a section about management. There are several reasons this section is here. First, even if you are not a manager, you may be a senior developer who provides guidance to others. Even if you are a junior programmer or the only person working on a project, you at least manage yourself. You may have little other control over your environment, but you should try to manage your own efforts properly.

Finally, if you are suffering from bad management, the following sections will help you understand what is happening and why. You may be able to improve your situation by discussing it with your boss or by leaving an anonymous copy of this book on his desk with certain key pages marked. At worst, you can decide for yourself whether bad management has destroyed any chance of success and it is time to update your resume.

You might think management would have little impact on the number and kinds of bugs in the code. Actually, both good and bad management can have a tremendous impact on developer productivity. By maintaining the right atmosphere, a good manager can help programmers produce more code with fewer bugs. By developing the wrong atmosphere, a bad manager can demoralize the team and make them produce less code containing more bugs.

The following sections explain attitudes you should have as a developer. They are also attitudes you should foster in others as a manager. If all of the team members share these attitudes, they can reduce the time wasted on bug chasing and spend more time writing code.

Fight Bugs Every Step of the Way

Think of bugs in a manic-depressive way. Be optimistic that all bugs can and will be found as quickly as possible. Be pessimistic about the chances of actually finding every last bug.

Bugs can and must be stopped before they enter working code. You cannot release code to other team members without thoroughly testing it first. The longer a bug remains undetected, the harder it is to fix. By testing new code immediately, you can stop bugs as soon as they are created and before they contaminate other developers’ code. It must be your goal to never affect another programmer or user by releasing code that contains a bug. This goal is ambitious, but realistic.

On the other hand, you must realize that some bugs will slip into the project no matter how careful you are. This means you must ruthlessly hunt for bugs throughout the entire project, from the initial requirements analysis phase to the final testing and documentation phases.

Bugs are not a force of nature that must be tolerated. They are something you can predict, hunt, corner, and kill. A bug is not some natural phenomenon that spontaneously appears in finished software just in time for demonstrations to corporate vice presidents.

Catch Bugs Early

Application development is sometimes portrayed in pyramid form as shown in Figure 1.1. The design at the bottom provides a solid foundation for the coding and testing that follow. Actually, the process is usually much more complicated. Figure 1.1 omits many of the details, including requirements analysis, definition of objectives, system behavior specification, test objective analysis, and so forth.

In a pyramid made of stone, the broad base spreads the weight of the stone at the top. If the base contains a weak brick, the others share the load so the pyramid does not crumble.

Unfortunately, the situation is somewhat reversed in software development. If a bug enters the project during the design phase, it will influence later development. Even if later code is implemented perfectly, it may still be wrong because it relies on incorrect assumptions in the earlier stages. A flaw at the bottom of the pyramid can spread through the later stages of development, as illustrated in Figure 1.2, until the entire structure crumbles.